Hi Neil,

This update allows imsm containers and member arrays to be discovered
with '-Eb' and subsequently assembled with '-As'.

For example here is a test for assembling a 4 drive container with (1)
4-disk raid5 array plus one spare.

# echo "DEVICES /dev/loop[0-4]" > tmp/mdadm.conf

# mdadm -Ebsc tmp/mdadm.conf >> tmp/mdadm.conf

# cat tmp/mdadm.conf
DEVICES /dev/loop[0-4]
ARRAY /dev/imsm metadata=imsm auto=md UUID=b98f5dbe-aa859e7b-0e369b89-a80986d4
ARRAY /dev/md/r1 container=/dev/imsm member=0 auto=mdp UUID=3538e39c-b397c2e9-1aa031f9-2bc0eca4
spares=1

# mdadm -Asvc tmp/mdadm.conf
mdadm: looking for devices for /dev/imsm
mdadm: /dev/loop4 is identified as a member of /dev/imsm, slot -1.
mdadm: /dev/loop3 is identified as a member of /dev/imsm, slot -1.
mdadm: /dev/loop2 is identified as a member of /dev/imsm, slot -1.
mdadm: /dev/loop1 is identified as a member of /dev/imsm, slot -1.
mdadm: /dev/loop0 is identified as a member of /dev/imsm, slot -1.
mdadm: added /dev/loop3 to /dev/imsm as -1
mdadm: added /dev/loop2 to /dev/imsm as -1
mdadm: added /dev/loop1 to /dev/imsm as -1
mdadm: added /dev/loop0 to /dev/imsm as -1
mdadm: added /dev/loop4 to /dev/imsm as -1
mdadm: Container /dev/imsm has been assembled with 5 drives
mdadm: looking to assemble member array 0 inside container /dev/imsm
mdadm: match found for member 0

I suppose brief_examine_super_imsm() can be updated to look at the
currently running kernel and not specify auto=mdp if the "extended
partition" capability is available. Is there a quick way to check for
this capability? You can see that I tagged this support as
"preliminary" as it does not attempt to address the multiple container
case, I left it alone for now as that solution depends on the device
name rework.

Please have a look.

Thanks,
Dan

The following changes since commit b01b06bda8dce132e6eb3c3826ad0f4b94ebdf43:
NeilBrown (1):
Merge branch 'master' into devel-3.0

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/djbw/mdadm.git devel

Dan Williams (7):
update copyright headers
imsm: update metadata immediately on "add spare" events
Examine: fix MD_DISK_SYNC is a bit not a flag
imsm: return associated uuid for spares
imsm: copy raid device info when associating spares
imsm: include members in ->brief_examine
Preliminary -As support for container member arrays

Assemble.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
Examine.c | 2 +-
Incremental.c | 6 ++++++
config.c | 2 ++
managemon.c | 19 +++++++++++++++++++
mdadm.h | 1 +
mdmon.c | 28 +++++++++++++++++++---------
mdmon.h | 20 ++++++++++++++++++++
monitor.c | 19 +++++++++++++++++++
sg_io.c | 2 +-
super-intel.c | 53 ++++++++++++++++++++++++++++++++++++++++++++---------
util.c | 9 +++++++++
12 files changed, 187 insertions(+), 20 deletions(-)


--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo [at] vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

On Tuesday October 28, dan.j.williams [at] intel.com wrote:
> Hi Neil,
>
> This update allows imsm containers and member arrays to be discovered
> with '-Eb' and subsequently assembled with '-As'.

Thanks Dan. There's definitely some useful stuff in here.
Some of it may be made a lot simpler by some revamping I hoping to get
done before the weekend...

>
> For example here is a test for assembling a 4 drive container with (1)
> 4-disk raid5 array plus one spare.
>
> # echo "DEVICES /dev/loop[0-4]" > tmp/mdadm.conf
>
> # mdadm -Ebsc tmp/mdadm.conf >> tmp/mdadm.conf
>
> # cat tmp/mdadm.conf
> DEVICES /dev/loop[0-4]
> ARRAY /dev/imsm metadata=imsm auto=md UUID=b98f5dbe-aa859e7b-0e369b89-a80986d4
> ARRAY /dev/md/r1 container=/dev/imsm member=0 auto=mdp UUID=3538e39c-b397c2e9-1aa031f9-2bc0eca4
> spares=1

I don't like the use of "/dev/imsm" is here. It obviously doesn't
scale to more that one imsm array, and while we all know that the
world doesn't need more than about 5 computers, I suspect someone out
there will find 1 IMSM array limiting :-)

My approach for the "/dev/imsm" in the first line is simple to discard
it. I've changed mdadm to allow the device name to be missing from
mdadm.conf and to not generate in for imsm and ddf. When "mdadm -As"
tries to assemble such a device it makes up a name, which may not be
stable between reboots. But if you are using mount-by-label then this
shouldn't be a problem. And that seems to be the way the world is
going.

The "container=/dev/imsm" is slightly harder to deal with. Just
leaving that out means there is no direct linkage between the two
lines. That might be a problem, except for the next point, which
somewhat makes it moot.

One change I'm introducing in 3.0 is that 'homehost' will never be
NULL. It now defaults to <system> which expands via 'gethostname()'.
One consequence of this is that
mdadm -As
will, after it has processed all it can find in mdadm.conf will
attempt auto-assembly of anything else it can find. Things that
aren't identified as belonging to 'this host' will still be assembled,
but with a guaranteed unique name.
This means that
mdadm -As
with an empty mdadm.conf will now assemble everything it can find.
Hopefully I'll get around to coding it so they are assembled
'read-auto'.

If you do
mdadm -Es > /tmp/mdadm.conf
mdadm -Asc/tmp/mdadm.conf

you will get one slight difference. Every array will be assumed to
belong to 'this' host (because they are listed in our local
mdadm.conf) and mdadm will be a little more generous in giving
meaningful names.
Also, the members of a container are local if the container is local,
so you don't really need to list the members in the output of "-Es".

I'll try to make sure it still works if the members are listed without
a "container=" setting. I toyed with the idea of supporting
"container=previous" or similar. It's a bit ugly though.

In short, I plan to take all you patches. Remove the references to
"/dev/imsm" and then make it all "do the right thing".

BTW, I'm currently prohibiting names like "/dev/imsm". You would need
to use "/dev/md/imsm". How much would that bother you?
I'm not completely committed to this, but it is a lot easier to impose
a more uniform naming scheme.

>
> I suppose brief_examine_super_imsm() can be updated to look at the
> currently running kernel and not specify auto=mdp if the "extended
> partition" capability is available. Is there a quick way to check for
> this capability? You can see that I tagged this support as
> "preliminary" as it does not attempt to address the multiple container
> case, I left it alone for now as that solution depends on the device
> name rework.

I'm tempted to allow the metadata to provide hints as to whether
partitions are needed. So you wouldn't need "auto=mdp" in mdadm.conf
- super-intel.c would somehow say "use partitions" (and 'ddf' would
say "don't") and mdadm would do as it is told.
The only way to check for the extended-minor-space is to check the
kernel version. I prefer to avoid doing that where possible as it
breaks when distros backport things, but I think in this case it is
justified (and if a distro did back-port the extended minor space
without updating mdadm it would all still work, just slightly
differently).

>
> Please have a look.

I have. Thanks.

I will try to have something credible on top of it pushed out by
tomorrow evening (24 hours from now). I might even call it
mdadm-3.0-devel2 (which I've been promising for a couple of weeks
without delivering).

Thanks,
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo [at] vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

On Wed, Oct 29, 2008 at 2:19 AM, Neil Brown <neilb [at] suse.de> wrote:
> The "container=/dev/imsm" is slightly harder to deal with. Just
> leaving that out means there is no direct linkage between the two
> lines. That might be a problem, except for the next point, which
> somewhat makes it moot.
>
> One change I'm introducing in 3.0 is that 'homehost' will never be
> NULL. It now defaults to <system> which expands via 'gethostname()'.
> One consequence of this is that
> mdadm -As
> will, after it has processed all it can find in mdadm.conf will
> attempt auto-assembly of anything else it can find. Things that
> aren't identified as belonging to 'this host' will still be assembled,
> but with a guaranteed unique name.
> This means that
> mdadm -As
> with an empty mdadm.conf will now assemble everything it can find.
> Hopefully I'll get around to coding it so they are assembled
> 'read-auto'.
>
> If you do
> mdadm -Es > /tmp/mdadm.conf
> mdadm -Asc/tmp/mdadm.conf
>
> you will get one slight difference. Every array will be assumed to
> belong to 'this' host (because they are listed in our local
> mdadm.conf) and mdadm will be a little more generous in giving
> meaningful names.
> Also, the members of a container are local if the container is local,
> so you don't really need to list the members in the output of "-Es".
>
> I'll try to make sure it still works if the members are listed without
> a "container=" setting. I toyed with the idea of supporting
> "container=previous" or similar. It's a bit ugly though.
>

What about container=<container uuid> as we can never really discern
with certainty the name of the container device at
->brief_examine_super() time?

> In short, I plan to take all you patches. Remove the references to
> "/dev/imsm" and then make it all "do the right thing".
>
> BTW, I'm currently prohibiting names like "/dev/imsm". You would need
> to use "/dev/md/imsm". How much would that bother you?
> I'm not completely committed to this, but it is a lot easier to impose
> a more uniform naming scheme.
>

I've been using /dev/imsm out of habit, but I can see how that might
cause problems with the /dev namespace. /dev/md/imsm makes more
sense.

> I will try to have something credible on top of it pushed out by
> tomorrow evening (24 hours from now). I might even call it
> mdadm-3.0-devel2 (which I've been promising for a couple of weeks
> without delivering).
>

Sounds good, thanks,
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo [at] vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

On Wednesday October 29, dan.j.williams [at] intel.com wrote:
>
> What about container=<container uuid> as we can never really discern
> with certainty the name of the container device at
> ->brief_examine_super() time?

Yes, could do that. It feels a bit ugly, but it probably makes sense.

But I've had another look at your 'provisional' thing and understand it
better and want to suggest some enhancements (Which might look like a
complete rewrite, but the important part of noticing the problem is
still yours :-)

You call Incremental_container from Assemble and that really isn't
right. Each call to 'Assemble' should assemble just one array, but
Incremental_container might assemble several.

Assemble() has the following basic structure:

1/ walk through list of available devices determining which ones
match the 'identity' of the required array.
2/ Check the set of devices for consistency and make any updates that
have been requested
3/ Assemble the array from the selected devices, and start it.

With a slight variation for the 'auto-assemble' case wherein the
'identity' to match is taken from the first device that is found to be
part of an array that is not already assembled.

To fit the assembly of a specific member of a container into this
model, we need to have the 'container' in the list of available
devices.
If the identity specifies 'container=whatever' then we clearly select
all devices which match that. You would expect at exactly one - the
container. You would then need to call ->container_content on that
container and find the correct member array which matches the
'member=' specifier (or any other specifier there might be?)

Exactly how updates and "--force" are passed though would need to be
sorted out.
Then the devices in the selected array from ->container_content could
be passed to sysfs_add_disk and the array started.

Auto-assembly would discover that the first unused-so-far device was a
container, and would need to load the list of arrays and assemble the
first one that was not yet assembled.

I think that is the 'right' thing to do, but it seems like a lot of
work just for now, so I might leave it for a while and see if
something else occurs to me.

Thanks,
NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo [at] vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

On Wednesday October 29, neilb [at] suse.de wrote:
>
> I will try to have something credible on top of it pushed out by
> tomorrow evening (24 hours from now). I might even call it
> mdadm-3.0-devel2 (which I've been promising for a couple of weeks
> without delivering).


Well, I didn't quite make that, things always take longer than you
expect.
But I have pushed out a 'scratch-3.0' which is my current working
code. Some of it will probably be revised which is why it isn't in
devel-3.0 yet. But it is there to be looked at (or laughed at?) and
maybe tested a bit.

You might like to run with

export MDADM_NO_UDEV=1

so that it doesn't depend on udev to create all the links, as some of
that doesn't quite work right yet.

NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo [at] vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

On Wed, 2008-10-29 at 20:42 -0700, Neil Brown wrote:
> To fit the assembly of a specific member of a container into this
> model, we need to have the 'container' in the list of available
> devices.
> If the identity specifies 'container=whatever' then we clearly select
> all devices which match that. You would expect at exactly one - the
> container. You would then need to call ->container_content on that
> container and find the correct member array which matches the
> 'member=' specifier (or any other specifier there might be?)
>
> Exactly how updates and "--force" are passed though would need to be
> sorted out.
> Then the devices in the selected array from ->container_content could
> be passed to sysfs_add_disk and the array started.
>
> Auto-assembly would discover that the first unused-so-far device was a
> container, and would need to load the list of arrays and assemble the
> first one that was not yet assembled.
>

I had a go at this, and the result is pushed out to my scratch-devel
branch. mdadm can now:

1/ Scan and assemble container members
mdadm -Es > mdadm.conf
cat mdadm.conf
ARRAY metadata=imsm auto=md UUID=88f0b659-966978a7-842f86c0-879a414d
ARRAY /dev/md/r1 container=88f0b659-966978a7-842f86c0-879a414d
member=0 auto=mdp UUID=42d6de62-bd27b267-96e8e960-13efc3a6
ARRAY /dev/md/r2 container=88f0b659-966978a7-842f86c0-879a414d
member=1 auto=mdp UUID=b0764c97-8b4fdf0e-0821862e-a80f1452
mdadm -Asc mdadm.conf
mdadm: Container /dev/md/imsm127 has been assembled with 6 drives
mdadm: Started /dev/md/r1 with 6 devices
mdadm: Started /dev/md/r2 with 6 devices

2/ Assemble member array by uuid
mdadm -A /dev/md/r1 /dev/md/imsm -a mdp -u 42d6de62-bd27b267-96e8e960-13efc3a6

3/ Auto-assemble member arrays as foreign arrays

This still does not handle updates or --force... it seems awkward to try
and support --force at anything other than the container level, but that
is the extent of my thinking so far.

The following changes since commit fb9253084ab0b9e4ac1113e4fc8f0b88d818d4f8:
NeilBrown (1):
mdopen: fix up name parsing.

are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/djbw/mdadm.git scratch-devel

Dan Williams (21):
Quiet uninitialized variable warnings
Makefile: fixup install of udev rules
imsm: match_home(), document why it is stubbed out
Let symlinks to standard devices count as standard names
imsm: display member array uuid in examine_super_imsm
imsm: display container uuid in detail_super
config: add 'containers' as a DEVICE keyword
Add a 'container' flag to mddev_dev_t
Assemble: check if the devlist entry is a container
Assemble: let trustworthy be LOCAL when array is identified
Assemble: replace 'info' with 'content'
Assemble: teach it to look inside containers for matching arrays
Assemble: discard non-container devices when not required
cleanup an unused call to container2devname
config: add containers to the default search list
Assemble: revert preliminary -As support
Copy container_dev in dup_super
Assemble: factor out and call assemble_container_content
fixup create_mddev
Assemble: block attempts to reassemble container members
Assemble: enable member array auto-assembly

Assemble.c | 428 ++++++++++++++++++++++++++++++++++++++-------------------
Incremental.c | 99 +------------
Makefile | 4 +-
config.c | 46 ++++++-
mdadm.c | 1 +
mdadm.h | 17 ++-
mdmon.c | 9 ++
mdopen.c | 7 +-
super-intel.c | 37 ++++--
util.c | 155 ++++++++++++++++++++-
10 files changed, 542 insertions(+), 261 deletions(-)


--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo [at] vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

On Sunday November 2, dan.j.williams [at] intel.com wrote:
> On Wed, 2008-10-29 at 20:42 -0700, Neil Brown wrote:
> > To fit the assembly of a specific member of a container into this
> > model, we need to have the 'container' in the list of available
> > devices.
> > If the identity specifies 'container=whatever' then we clearly select
> > all devices which match that. You would expect at exactly one - the
> > container. You would then need to call ->container_content on that
> > container and find the correct member array which matches the
> > 'member=' specifier (or any other specifier there might be?)
> >
> > Exactly how updates and "--force" are passed though would need to be
> > sorted out.
> > Then the devices in the selected array from ->container_content could
> > be passed to sysfs_add_disk and the array started.
> >
> > Auto-assembly would discover that the first unused-so-far device was a
> > container, and would need to load the list of arrays and assemble the
> > first one that was not yet assembled.
> >
>
> I had a go at this, and the result is pushed out to my scratch-devel
> branch.

Thanks. I took your code, kept some bits, fixed some bits, rewrote
other bits and completely replaced some more :-) And added some of my
code too.

I've just pushed the result to my devel-3.0 branch

git pull git://neil.brown.name/mdadm devel-3.0

It get a clean "make everything" and the self tests all run (I hope -
it's late and I cannot wait for the final run).

Tomorrow I'm going to hack at the man page, and write some more test
scripts.

With the current code

mdadm -As

should find and assemble all of your arrays. And give fairly useful
names.

I haven't included your

Let symlinks to standard devices count as standard names

patch because I don't think I agree with it, and I don't think it is
needed any more.

I also have left out your

imsm: match_home(), document why it is stubbed out

because I don't understand. Maybe some more words about how
'family_num' can distinguish between "Local" and "Foreign". ??

Thanks heaps,

NeilBrown

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo [at] vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Neil Brown wrote:
> I haven't included your
>
> Let symlinks to standard devices count as standard names
>
> patch because I don't think I agree with it, and I don't think it is
> needed any more.
>

My concern was that:
for i in `seq 1 5`
do
mdadm -As
mdadm -Ss
done

....would create 5 different device numbers. Your right it is better
now, but between successive assemblies the device numbers still toggle
between two different values. So it's just a small cosmetic issue now.
Are their lifetime issues that preclude predictable device numbers?

> I also have left out your
>
> imsm: match_home(), document why it is stubbed out
>
> because I don't understand. Maybe some more words about how
> 'family_num' can distinguish between "Local" and "Foreign". ??
>

....it doesn't. 'family_num' is a checksum that includes the serial
numbers of the component disks when the array was first created. So it
can help determine when two arrays were created in different places, but
the metadata can't identify which, if any, is "Local".

I'll redo the comment.

Thanks for the pull and the review,
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo [at] vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[ added linux-raid with permission ]

On 8/16/2010 5:17 PM, K. Posern wrote:
> Dear Mr. Williams,
>
> I am a bit desperate that's why I dare to contact you like this:
> As I did not find any answer to my below 2 questions in man-pages, in
> the source-code (quick look with grep+less), on irc channels and of
> course with google, I am hoping that you can give me any hint or refer
> me to somebody who might.
>
> I adore Intels engagement for linux. Unfortunately is there no website
> (yet?): "intellinuxraid.org" (like there is: intellinuxgraphics.org).

There is no website. My personal thought is that we should extend the
content at raid.wiki.kernel.org.

> The only official information from intel I could dig up so fare states:
> imsm is supported with mdadm >=v3 and dmraid >=v1
>
> But I am trying to find out if it is possible to:
>
> a) Autoassemble the RAID (so avoid having an initrd)

No, the auto-assemble I mentioned in the pull request will not avoid
having an initrd. You are thinking of "in-kernel autodetect" which is
not supported with the imsm metadata format (or any metadata format
besides the md-v0.90 format). In general assembling arrays in userspace
is much more flexible which is why you see the in-kernel autodetect code
has been put in a no-new-features/maintenance-only mode.

I know Fedora and OpenSUSE have added support for this configuration to
their initrd tools.

> b) BOOT linux from this: grub2? lilo? ... anything?

One of the primary benefits of using the Intel(R) RST (mdadm-imsm)
format is that you can use the platform bios option-rom to boot from
raid. So grub, grub2, lilo, or any other bootloader can boot from raid.
This is because the option-rom installs a bios int13 handler that
allows the bootloader to read from a raid volume as if it were a
standalone disk.

> About (a):
> The git pull request seems to indicate thate there is auto-assembly
> support for imsm software raids?!
> Is this true? - again: grep

The "mdadm -As" command will search all available disks and
automatically assemble all the imsm arrays that it finds.

> What RAID-Levels (for an imsm fakeraid) are supported?

I think the 'fakeraid' moniker is tired and misplaced when referring to
this new functionality in md/mdadm. There is nothing fake about Linux
software RAID. I prefer "bios-raid" or even "software raid".

Current platforms ship support for raid levels 0, 1, 10, and 5.

> Especially: What about RAID-0?

Supported.

>
> About (b):
> According to "Kyron" and his wiki:
> http://wiki.neuralbs.com/index.php/Gentoo_Quick_Install_note s#GRUB2
> grub2 should support imsm (but grep for imsm in the Bazaar checkout does
> not yield any hit) <<< I contacted the grub2 mailing-list for clarification

Like I mentioned above, the bootloader does not need any special code to
boot from a bios-raid array because it can use standard int13 services.

> I really hope you can help me. Most importantly with question (a).
>
>
> Yours sincerely,
>
> K. Posern
>

Regards,
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo [at] vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

> -----Original Message-----
> From: Williams, Dan J
> Sent: Tuesday, August 17, 2010 9:49 AM
> To: K. Posern
> Cc: linux-raid [at] vger.kernel.org; Jiang, Dave
> Subject: Re: [mdadm git pull] "--assemble --scan" support for imsm
>
> [ added linux-raid with permission ]
>
> On 8/16/2010 5:17 PM, K. Posern wrote:
> > Dear Mr. Williams,
> >
> > I am a bit desperate that's why I dare to contact you like this:
> > As I did not find any answer to my below 2 questions in man-pages, in
> > the source-code (quick look with grep+less), on irc channels and of
> > course with google, I am hoping that you can give me any hint or
> refer
> > me to somebody who might.
> >
> > I adore Intels engagement for linux. Unfortunately is there no
> website
> > (yet?): "intellinuxraid.org" (like there is: intellinuxgraphics.org).
>
> There is no website. My personal thought is that we should extend the
> content at raid.wiki.kernel.org.

I have updated raid.wiki with the external metadata information a few weeks back. Please take a look and let me know if additional information is required. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo [at] vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

This is a cryptographically signed message in MIME format.

--------------ms070008000303030407090702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Dear Mr. Williams,

Thank you *very* much... you added very valueable pieces to my imsm
RAID(-0) puzzle.

I just used the term "fakeraid" because it is *short* :) ... I did not
mean it negative. Plus a lot of people use this term:
https://secure.wikimedia.org/wikipedia/en/wiki/RAID#Firmware .2Fdriver-ba=
sed_RAID_.28.22FakeRAID.22.29
The Ubuntu FakeRAID HowTo
ArchLinux FakeRaid Howto

I would really like a new point on the raid-wikis first page named along =

these lines:
"[Intel] Firmware-based/BIOS-supported RAID ("FakeRAID")"
And I can do this if you want (aready created account yesterday).

On there should be a
- short description about what what a "fakeraid" is
- then for INTEL the info you get when you google for "intel linux raid"=

- the info from Dan's answer below. Especially the part with "the
option-rom installs a bios int13 handler" (because there /is/ confusion
about that out there :).
- Also the answer to the belows question: "How to install a bootloader" =

should be on there.

And of course the more technical details the better. Eg.
- that (and maybe why) the primary partitions setup within the imsm
raid(-0) will be created on the first physical drive (/dev/sda), but not =

on the other drives.
- maybe even more in depth details on the external metadata format
- maybe some commonly used commandlines for mdadm and dmraid to check
the raid status ... or at least links to their howtos/wikis...

You mentioned:
> One of the primary benefits of using the Intel(R) RST (mdadm-imsm)
> format is that you can use the platform bios option-rom to boot from
> raid.
2 questions:
a) What does RST stand for?
b) Does the (mdadm-imsm) mean, that the device-mappers "dmraid -f isw"
does not the same (or does intel just officially only support mdadm imsm?=
)

And finally: Can anyone tell me which solution:
dmraid -f isw
mdadm with imsm container support
is better in the sense:
- faster (higher throughput)
- less load (e.g. on cpu)
- more stable
- more features
I already posted this question to the dm-devel [at] redhat.com mailing list
but (afaik) never got an answer.

Also: What I find odd with the dmraid solution: In fdisk it shows you
e.g. /dev/dm-0p6, but there is no /dev/dm-0p6, there is only /dev/dm-0
to /dev/dm-11 and many /dev/mapper/LONGNAME symlinks to the /dev/dm-*.
But the /dev/mapper/Volume_HASH_06 points to /dev/dm-4 ?!.... IMHO:
total mess.

--------------

"How to install a bootloader"?

You mentioned:
> One of the primary benefits of using the Intel(R) RST (mdadm-imsm)
> format is that you can use the platform bios option-rom to boot from
> raid. So grub, grub2, lilo, or any other bootloader can boot from raid=
=2E
> This is because the option-rom installs a bios int13 handler that allo=
ws
> the bootloader to read from a raid volume as if it were a standalone
disk.

Which sounds great, but I can send you the chatlog from the #grub
channel this morning... they don't seem to have an idea about that.

Could you/someone be so kind to provide me with the steps to manually
install grub (legacy v0.97) or grub2 (v1.98) on a linux that accesses
the raid via mdadm-imsm (/dev/md126, /dev/md127)?

Because for me it seems: "Intel" says: grub, gub2: No problem. "Grub"
says: ???
I know that this is not a grub mailing list, but maybe just a small
hint? Like: What should be in /boot/grub/device.map?
/dev/md126?
Do I install grub to the container (/dev/md127) or to the volume
(/dev/md126)?
E.g.
- grub legacy gave me a "Error 22" on "setup (hd0)" with "/dev/md126 as
(hd0) in device.map
- grub2: 1st it seems unclear what should be in the /dev/md, because
grub assembles /dev/mdadm raids (independent of the BIOS), 2nd it seems
unclear how this internal mdadm assembly interferes with "accessing the
RAID via the int13 handler as a standalone disk"
- lilo: I would prefer a grub based solution

Again: Maybe this information is somewhere out there, but that's the
problem: There are bits and pieces [about Intel BIOS supported RAID
imsm] all over the place --> That's why I would love to (help to) create =

this wiki page I mentioned earlier to just assemble the most basic
things in one place.
=2E. Also that next time a guy like me (with a lot of half-knowledge ;)
comes along and asks many "stupid" questions about imsm integration you
can hopefully just point him to this wiki page.
Does this make sense to you too?


Any hint will be greatly appreciated!

K. Posern

--

On 17/08/10 12:49, Dan Williams wrote:
> [ added linux-raid with permission ]
>
> On 8/16/2010 5:17 PM, K. Posern wrote:
>> Dear Mr. Williams,
>
=2E.. <relevant parts pasted above>
> Regards,
> Dan




--------------ms070008000303030407090702
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIKajCC
BTEwggMZoAMCAQICAwYm8zANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdS b290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENl cnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9y ZzAeFw0wODEy
MTIxOTEzNDFaFw0xMDEyMTIxOTEzNDFaMDsxFTATBgNVBAMTDEtudXRoIFBv c2VybjEiMCAG
CSqGSIb3DQEJARYTcXVpY2toZWxwQGdtYWlsLmNvbTCCASIwDQYJKoZIhvcN AQEBBQADggEP
ADCCAQoCggEBAM/XLQlhOxcmVwIU0kEDlqL9OiNezGZpMhzB/c1ibGEfBxC0 v6GfQd+k00a0
tL4uzwNHquu3Lk49cc9AJbIUbppd9H0RY1dD9FpjjC8SmPlb9ZofRSr7lPlD fD4A8EqLw7KB
sp3yUs1kl7SYKAlX7JJgCqzo+CxxOEuO11dnv/ruezOMyGRPOBBMCPiPLyr7 iOjkvWObgIoC
82f4EhfsXNPTV3z2b2s1k/0JPIr1t2klk8bta/8MdjSF6E3SjJyyXp0mq48i zityMpi5J0U3
Gz2G9EIUBRILVSY/ZZQz2W8Ur2jhItSbpY1qLv6aSCFsrPsFOyc8HEHUaJ+S wF0WbD0CAwEA
AaOB/zCB/DAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQg eW91ciBvd24g
Y2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cu Q0FjZXJ0Lm9y
ZzBABgNVHSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQBgjcKAwQG CisGAQQBgjcK
AwMGCWCGSAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0 dHA6Ly9vY3Nw
LmNhY2VydC5vcmcwHgYDVR0RBBcwFYETcXVpY2toZWxwQGdtYWlsLmNvbTAN BgkqhkiG9w0B
AQUFAAOCAgEAzBJqLQB9q+ZEfvidFXWVNyfEiRmvDbvOdsg+6Pl38RqKHcho ZpdqsfyZV3Lv
XQ3JGhqTNFQTiwt1iO4a4Ww3PsxiL8vUifznjVRD+pe6kx+HU2asNXvm1CzG 6dB2h8GuPep0
GfAz3P0xpi7x+drws/ll4FaI0QjF2IMuzfOEduQ6JpKwYFxSDF6kUlDZxONu nRQlMSQg8WgX
5Wd+Vvb89yOojXcF4MgaCBmgJ0X8sfgLv01iIPd+NOhCX4+Ipw39qakLon1o 8ng4TvDYJEQ0
XkEL4aQ5bpFlc/LxeKpIH7nc8DptRCD5cNjaZp+gPcs6Z02E0e3ImbohO0VG 6LIajq9lPxpn
x7u/TdbmbTLPaTLcpM9y5Ojp4JsMfx2s/7fKLTARzCnt+iGD071BkjPJQKqV ymkWO75PB0uq
7X0zSIF0zYDmuaaVe3F+Smz2hkpx+JyV4BOOH1kyrzMPSHuBSpd6RUd1KUPg NeXz5RTtJuoo
Jyv6UhlUtF6weBbwhrl9KNW5ypcuo+Mkl3oauqhtaZS2ywZInq0XjzSKPvUV tUlfRGEUliKi
0PNnXKJHqh+4HAwx2J37iTDGpkOq4DC10226nn74IfalQaz0lQKpFWc7V3eP k/SPnu+Hy96L
Cjk7SQcj4SrLMLDfvDi7O2Gk22RGe48eDcRLVdiCyzv+YEwwggUxMIIDGaAD AgECAgMGJvMw
DQYJKoZIhvcNAQEFBQAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMV aHR0cDovL3d3
dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9y aXR5MSEwHwYJ
KoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcNMDgxMjEyMTkxMzQx WhcNMTAxMjEy
MTkxMzQxWjA7MRUwEwYDVQQDEwxLbnV0aCBQb3Nlcm4xIjAgBgkqhkiG9w0B CQEWE3F1aWNr
aGVscEBnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDP1y0JYTsX
JlcCFNJBA5ai/TojXsxmaTIcwf3NYmxhHwcQtL+hn0HfpNNGtLS+Ls8DR6rr ty5OPXHPQCWy
FG6aXfR9EWNXQ/RaY4wvEpj5W/WaH0Uq+5T5Q3w+APBKi8OygbKd8lLNZJe0 mCgJV+ySYAqs
6PgscThLjtdXZ7/67nszjMhkTzgQTAj4jy8q+4jo5L1jm4CKAvNn+BIX7FzT 01d89m9rNZP9
CTyK9bdpJZPG7Wv/DHY0hehN0oycsl6dJquPIs4rcjKYuSdFNxs9hvRCFAUS C1UmP2WUM9lv
FK9o4SLUm6WNai7+mkghbKz7BTsnPBxB1GifksBdFmw9AgMBAAGjgf8wgfww DAYDVR0TAQH/
BAIwADBWBglghkgBhvhCAQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmlj YXRlIGZvciBG
UkVFIGhlYWQgb3ZlciB0byBodHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0l BDkwNwYIKwYB
BQUHAwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgB hvhCBAEwMgYI
KwYBBQUHAQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQu b3JnMB4GA1Ud
EQQXMBWBE3F1aWNraGVscEBnbWFpbC5jb20wDQYJKoZIhvcNAQEFBQADggIB AMwSai0Afavm
RH74nRV1lTcnxIkZrw27znbIPuj5d/Eaih3IaGaXarH8mVdy710NyRoakzRU E4sLdYjuGuFs
Nz7MYi/L1In8541UQ/qXupMfh1NmrDV75tQsxunQdofBrj3qdBnwM9z9MaYu 8fna8LP5ZeBW
iNEIxdiDLs3zhHbkOiaSsGBcUgxepFJQ2cTjbp0UJTEkIPFoF+Vnflb2/Pcj qI13BeDIGggZ
oCdF/LH4C79NYiD3fjToQl+PiKcN/ampC6J9aPJ4OE7w2CRENF5BC+GkOW6R ZXPy8XiqSB+5
3PA6bUQg+XDY2mafoD3LOmdNhNHtyJm6ITtFRuiyGo6vZT8aZ8e7v03W5m0y z2ky3KTPcuTo
6eCbDH8drP+3yi0wEcwp7fohg9O9QZIzyUCqlcppFju+TwdLqu19M0iBdM2A 5rmmlXtxfkps
9oZKcficleATjh9ZMq8zD0h7gUqXekVHdSlD4DXl8+UU7SbqKCcr+lIZVLRe sHgW8Ia5fSjV
ucqXLqPjJJd6GrqobWmUtssGSJ6tF480ij71FbVJX0RhFJYiotDzZ1yiR6of uBwMMdid+4kw
xqZDquAwtdNtup5++CH2pUGs9JUCqRVnO1d3j5P0j57vh8veiwo5O0kHI+Eq yzCw37w4uzth
pNtkRnuPHg3ES1XYgss7/mBMMYIDlDCCA5ACAQEwgYAweTEQMA4GA1UEChMH Um9vdCBDQTEe
MBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBD ZXJ0IFNpZ25p
bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwYm8zAJ
BgUrDgMCGgUAoIIB6DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEP
Fw0xMDA4MTgxNzQ5NDJaMCMGCSqGSIb3DQEJBDEWBBSz/M0Xs1P5dsNYU2vI nh6TNfP/rTBf
BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggq hkiG9w0DAgIC
AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgZEG CSsGAQQBgjcQ
BDGBgzCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8v d3d3LmNhY2Vy
dC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAf BgkqhkiG9w0B
CQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDBibzMIGTBgsqhkiG9w0BCRACCzGB g6CBgDB5MRAw
DgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5v cmcxIjAgBgNV
BAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEW EnN1cHBvcnRA
Y2FjZXJ0Lm9yZwIDBibzMA0GCSqGSIb3DQEBAQUABIIBAHjzStKvS4aCxWWD SjoxxW7/Ek2w
LBRywOV7ErS0Zpg38TaGFEzIASB1X8byFW5hZRfJzt6YKWrpNNdQDkFI8it5 +qxE8uCKlQ5n
8hFU1T5TMhcT4Yzq3Rk2EjSld40sPhZaAUvYDZCNs/pLU2frcSwBn9ZCQlb3 eTKan4WTezNC
Za7dpab3ZL2mvU5g4BhKlRVYWWjpVG3U9lj4sch9nSjs2rRm62142eVyLYsM N+MhMBZl32l0
HdXLl2rmNyOotdupke6yLxPaxLlp4ke065JXT5LqSoDjdGkQFU2GVq3zdHqe 3NXZZ1O37mvs
aqY7FFT/4uQXel+ghhKZWVrvrIkAAAAAAAA=
--------------ms070008000303030407090702--
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo [at] vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html